Conventional operating systems such as Microsoft Windows, GNU/Linux or the like were not designed with strong security constraints. The result is weakly secured design in the form of a two-layer operating system: the first layer consists of the kernel run in a privileged mode and the second layer consists of the applications which are run in an unprivileged mode called the user mode. The kernel is typically a monolithic kernel, even if a modular approach is chosen for managing in particular all of the resources offered by the operating system. The kernel includes the low-level software such as the scheduler, the process manager, the memory manager as well as the peripheral drivers and some high-level services such as the file systems, the network stacks, the encryption algorithms, etc.
Accordingly, the kernel comprises millions of code lines with a proportional number of bugs and security flaws. It cannot therefore be verified as compliant with the specifications using the current code verifiers and official proof systems. In addition, they have poor isolation properties. As a matter of fact, the user processes can break the isolation in various ways owing to the tubes, the files, the shared memory, etc. Management of the inter-process communications is not reliable. Furthermore, there is no isolation inside the kernel, or between sub-systems of the kernel, e.g., such as between the drivers and the network stacks. Thus, a bugged or corrupt hardware component driver can endanger the entire system.
As security risks increase, kernel designers have attempted to secure the existing kernels by adding mandatory access managers (Mandatory Access Control—MAC) with a small granularity for implementing the “Reference Monitor” concept. As a matter of fact, current operating systems generally implement Discretionary Access Control (DAC), which cannot solve the generic problem of malicious codes, and especially viruses. Examples of operating system security enhancements are SELinux, GRSecurity, AppArmor, RSBAC, SEBSD, etc.
However, these implementations do not meet the requirements of the Reference Monitor because the security functions forming part of the kernel are not protected and are unusable within the kernel domain: they do not offer any protection between sub-systems of the kernel. Furthermore, since these kernels manage all of the system resources, it is difficult to establish a security policy, and the result is complex, in terms of configuration and management, thereby making official verification impossible.
All of these weaknesses make official verification of the protection offered by these operating systems impossible and produce a number of security threats which limit the use of these systems in environments having a high security requirement. Furthermore, the kernel memory space is shared amongst all of the processes, and with all the sub-systems, even if they belong to different security levels. Consequently, the current operating systems do not offer a healthy and secure environment.
As a reaction to the complexity of current monolithic kernels, researchers have proposed the concept of a microkernel, which is characterized by the movement of a maximum number of services outside the kernel, into the user space. These functionalities are then provided by small independent servers possessing their own address space.
The microkernel is thus limited to a few basic functions including management of the communications between the servers, which are carried out via message transfer (IPC-Inter Process Communication). In addition to this management, a microkernel includes a clock driver and a scheduler.
Thus, while a traditional monolithic kernel comprises several million lines of code, a microkernel generally comprises less than 20,000 lines of code.
The attraction of secure system designers for microkernels is thus understood, since they are of a size which enables them to be easily maintained and they can be specifically verified. They can thus be certified at the highest level, EAL7, of the Common Criteria.
One of the most widely known and currently used microkernels in various alternatives is the L4 microkernel designed and implemented by Jochen Liedtke.
However, along with the microkernel itself, it becomes necessary to develop the necessary servers for the system to offer the functionalities expected from a modern operating system.
Therefore, in order to avoid complete rewriting of an operating system, it has been proposed to use the microkernel as a virtualization hypervisor base on which one or more traditional operating systems are run. As a matter of fact, a microkernel and all of the management servers required for partitioning the resources natively perform the function of a hypervisor, namely that of partitioning the available resources between the virtual machines and emulating hardware events (they do not comprise the peripheral drivers, only non-shareable system buses), thereby offering a high-performance native virtualization technology, also known as “system” level.
It is in this way that the L4 Linux project of the University of Dresden (Germany) brought the Linux kernel over to the L4/Fiasco microkernel and the layer of services thereof, thereby creating a (para) virtualized LINUX running on top of a hypervisor, in a completely unprivileged mode, in user mode.
In terms of security, such a system benefits from the reliability of the microkernel. However, the security of the servers likewise depends on the reliability of the IPC communications, because it is a possible means of transmitting harmful data. Such being the case, for reasons of efficiency, communications security management is traditionally left to the servers, the microkernel being content with transmitting the messages. The microkernel can, however, offer a communication rights mechanism; two tasks can communicate with one another only if they have the appropriate rights. In the opposite case, the communication is redirected to a specific communications control server which will authorize or not authorize the communication “on-the-fly”, based on the security policy.
In addition, current microkernel architectures are such that security policy is “hardwired” into the access rules of the microkernel whereby, even in a virtualization context with several virtual machines, they all have the same security policy.
It would thus be particularly advantageous to have secure microkernel architecture which enables good control of virtual machine access as well as granularity and flexibility in the implementation of one or more security policies with regard to a single system.